…op losing write warnings (framework#3794)

The record page told the user the opposite of what the backend does, in both
directions.

The approval band rendered "Locked for approval" on any pending request,
ignoring the node's `lockRecord`. A `lockRecord: false` node is pending WITHOUT
locking — that is how an approver amends a record while deciding on it — so the
band hid the feature; meanwhile the header Edit button stayed enabled on a
genuinely locked record, letting the user fill a form the save would reject with
RECORD_LOCKED. `useRecordApprovals` now reads `locks_record` off the pending
request (framework#3794), `RecordDetailView` derives `approvalPending` and
`approvalLocked` separately and threads both through `InlineEditProvider`, and
the band picks the amber lock or a neutral "In approval (editable)" from the
host's signals. With no approvals-aware host the `approval_status` fallback is
unchanged and still assumes a lock.

The write-warning toast (framework #3431/#3455) never fired on
`batchTransaction`, which is the record form's save path for a master-detail
record — precisely where a user edits a `readonlyWhen`-locked field. It now
emits per event, resolving each back to its operation via the response `index`.
The toast is localized (en + zh) and worded by reason: a `readonly_when` strip
says the field is not editable in this record's current state, not that it is
read-only.

Finally, the user-state adapter no longer hand-stamps the server-managed
`updated_at`, which the server strips and reports — that fired a "Some fields
were not saved" warning about a field no user touched, on ordinary page loads.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The approval-band half of this PR landed independently as #2906 while it
was open, so the merge is mostly a de-duplication. Resolved toward main
for everything #2906 already shipped, keeping only what is genuinely new
here.

Taken from main wholesale:
- `useRecordApprovals` — main's `lock_record` + `recordLockedByApproval`.
  This PR's field name `locks_record` was simply wrong: framework#3834
  merged as `lock_record`, which is what the server actually sends.
- `InlineEditContext` — identical `approvalPending` contract; no diff left.
- the band's markup/styling (sky "In approval · editable" variant) and the
  `approvalPendingEditable` / `approvalPendingTooltip` key names, dropping
  this PR's `inApprovalEditable*` spelling of the same two strings.

Kept from this branch:
- `disabled: approvalLocked` on the header Edit CTA. #2906 gated inline
  edit but left the full-form CTA live on a locked record, so the user
  still filled a screen before Save returned RECORD_LOCKED.
- `DetailView` no longer OR-s the `approval_status` mirror into `isLocked`
  unconditionally. A flow configuring an `approvalStatusField` mirrors
  `approval_status: 'pending'` regardless of `lockRecord`, so on a
  `lockRecord: false` node main's derivation re-locked the band while the
  host had correctly resolved "not locked" — pencils live and saves
  landing under a band reading "Locked for approval". `approvalPending &&
  !locked` is the tell that the host has an opinion (the provider defaults
  `approvalPending` to `locked`, so a pre-#2902 host can never produce it).
  Covered by a new test.
- the recall tooltip's unlocked variant, and everything in parts 2 and 3
  (batch `droppedFields` warnings, the localized by-reason toast, and
  dropping the hand-stamped `updated_at`), which main never touched.

Also drops a duplicate `Clock` import git merged in from both sides.

Green: 2849 tests across plugin-detail / data-objectstack / i18n / react /
app-shell; `pnpm type-check` clean on all 76 packages; 0 lint errors.